The World of Computer Software/The World of Computer Software.iso/vl6-005.zip/VL6-005.TXT

Text File | 1993-01-08 | 43KB | 1,033 lines

 From [e-mail]  Thu Jan  7 06:52:32 1993
 Received: from fidoii.CC.Lehigh.EDU by abacus.hgs.se (5.65c/2.0)
     id AA10431; Thu, 7 Jan 1993 17:56:32 +0100
 Received: from  (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA20246
   (5.67a/IDA-1.5 for <[e-mail]>); Thu, 7 Jan 1993 11:52:32 -0500
 Date: Thu, 7 Jan 1993 11:52:32 -0500
 Message-Id: <[e-mail]>
 Comment: Virus Discussion List
 Originator: [e-mail]
 Errors-To: [e-mail]
 Reply-To: <[e-mail]>
 Sender: [e-mail]
 Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
 From: "Kenneth R. van Wyk" <[e-mail]>
 To: Multiple recipients of list <[e-mail]>
 Subject: VIRUS-L Digest V6 #5

 VIRUS-L Digest   Thursday,  7 Jan 1993    Volume 6 : Issue 5

 Today's Topics:

 Re: Untouchable (PC)
 Re: Untouchable (PC)
 noint - what is it? (PC)
 Re: Untouchable (PC)
 Re: Invalid Boot Sectors (PC)
 Known virus that tweaks PC date function? (PC)
 Re: Clash between FDISK/MBR and scanners (PC)
 Re: Invalid Boot Sectors (PC)
 Joshi Question (PC)
 PKZIP V2.04C (PC)
 False positive in the new PKZIP (PC)
 Info on Music Bug virus (PC)
 New Virus (PC)
 Re: Vshield vs Virstop (PC)
 Re: Jerusalem (Israeli) Virus (PC)
 Clearing out old signatures (PC)
 DOS Serial Numbers (PC)
 Viral Code Access
 Re: The Internet Worm (CVP)
 Re: Good use of (possible bad) viruses
 Export restrictions of anti-virus software?
 How to measure polymorphism?

 VIRUS-L is a moderated, digested mail forum for discussing computer
 virus issues; comp.virus is a non-digested Usenet counterpart.
 Discussions are not limited to any one hardware/software platform -
 diversity is welcomed.  Contributions should be relevant, concise,
 polite, etc.  (The complete set of posting guidelines is available by
 FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with
 your real name.  Send contributions to [e-mail].
 Information on accessing anti-virus, documentation, and back-issue
 archives is distributed periodically on the list.  A FAQ (Frequently
 Asked Questions) document and all of the back-issues are available by
 anonymous FTP on cert.org (192.88.209.5).  Administrative mail
 (comments, suggestions, and so forth) should be sent to me at:
 <[e-mail]>.

    Ken van Wyk

 ----------------------------------------------------------------------

 Date:    28 Dec 92 23:48:00 +0000
 From:    [e-mail] (Bill Lambdin)
 Subject: Re: Untouchable (PC)

 Quoting from Vesselin Bontchev to All About Re: Untouchable (PC) on
 12-07-92

 VB> One important thing to have in mind is that the product is very good,
 VB> but not as good as the advertisements are trying to suggest you. Some
 VB> advertisements (in France) say that it is "the absolute weapon agains
 VB> computer viruses" and that no virus, even an unknown one, is able to

 I agree 100%.

 Untouchable is capable, but I wouldn't do much farther. I have Untouchable
 1.13.

 UTScan
 Detection is fair
 removal leaves a lot to be desired.

 I would place F-Prot, VIRx, and Scan in front of it.

 UTRes
 Detection is fair.

 UTPeriodic
 This is one of the best integrity checkers that I have seen. I would put
 it in the same league with Victor Charlie's Bit Checking, or Integrity
 Master.

 The advertising for Untouchable is doing them a dis-service.

 Untouchable is good, but not THAT good.

 Bill

 - ---
  * WinQwk 2.0 a#383 * Hacked version of Math Master MATHMSTR.*


 ------------------------------

 Date:    29 Dec 92 00:05:00 +0000
 From:    [e-mail] (Bill Lambdin)
 Subject: Re: Untouchable (PC)

 Quoting from Y. Radai to All About Re: Untouchable (PC) on 12-08-92

 YR>   UTSCAN has the ability to examine archives and compressed executa-
 YR> bles (recursively), includes one of the better MtE detectors (its

 Untouchable does well at scanning archives, abd files compressed with
 PKlite, LZEXE, Diet, and maybe others.

 However; I performed some tests with PKlite 1.15 recently. McAfee's Scan
 was able to detect the virus inside the file compressed with PKlite 1.15.
 Untouchable wasn't able to scan inside the file.

 I hope that UTScan can be updated to work with compressed files created
 with PKlite 1.15 and above.

 Bill

 - ---
  * WinQwk 2.0 a#383 * SURIV 3.0 activates Friday the 13th


 ------------------------------

 Date:    29 Dec 92 07:40:00 +0000
 From:    [e-mail] (Bill Lambdin)
 Subject: noint - what is it? (PC)

 Quoting from Gang Wu to All About noint - what is it? (PC) on 12-23-92

 GW> anyone has any idea what noint virus is? we discovered several of the
 GW> here in barnard college and it seemed that the virus can physically
 GW> destroy the floppy disk (all the disks we found infected by this viru
 GW> has numerous bad sectors after the infection.)

 No-Int is a stealth boot sector virus. Sometimes called Stoned 3.

 This is the virus that was accidentaly distributed by Novel about a year
 ago.

 Bill

 - ---
  * WinQwk 2.0 a#383 * MICHELANGELO activates Mar 6th

 ------------------------------

 Date:    29 Dec 92 01:37:00 +0000
 From:    [e-mail] (Bill Lambdin)
 Subject: Re: Untouchable (PC)

 Quoting from Y. Radai to All About Re: Untouchable (PC) on 12-12-92

 YR> I was referring to Ver. 26 of UTScan.

 I am using version 25.10 of UTScan.

 When was 26 released?

 Bill

 - ---
  * WinQwk 2.0 a#383 * CASINO activates Jan 15th

 ------------------------------

 Date:    Tue, 05 Jan 93 17:58:25 -0500
 From:    [e-mail] (A. Padgett Peterson)
 Subject: Re: Invalid Boot Sectors (PC)

 >From:    "Roger Riordan" <[e-mail]>

 >I recently wrote

 >>In a recent comment on a query by [e-mail]
 >>(Michael Purcell) about a virus which allegedly made disks
 >>unreadable I wrote.

 >>> If you put the wrong byte in the wrong place you can get the
 >>> symptoms described.  ...

 >It appears the original message got lost, but the gist was that,
 >IN THEORY, it is possible to write a BS virus which is invisible
 >on an infected PC, but impossible to detect on an uninfected PC
 >with any existing scanner because DOS will crash if any attempt is
 >made to access an infected disk.

 This is something that experimentation has been done on. What I have
 found is that:

 a) If the Partition table is missing certain DOS signature bytes, DOS
    will refuse to recognise the disk (but a floppy boot will still work).

 b) If certain bytes in an otherwise good P-Table have certain wrong values
    a floppy boot may hang (which bytes and what values are DOS version
    dependant).

 c) Even given (a) or (b), BIOS software can restore bootability (I have
    a version of FIXMBR that loads and runs from the BIOS just like
    the early Microsoft Flight Simulator).

 d) *Every* MBR infection that I have seen is detectable if you
    look in the right places. "Stealth" can always be bypassed with a
    direct BIOS call.

 In other words, every infection I have seen is recoverable with the
 right tools (usually DEBUG, FDISK, & SYS). Sometimes it is not worth
 the bother since repair via E-Mail is somewhat more difficult, but
 whatever is not corrupted can be retrieved and that which has been
 corrupted can usually be restored. In general I have found that the
 stupider the program, the more likely it will work.

 I am glad that the above said "IN THEORY" since an undetectable,
 invisible virus that can make a system completely unbootable except
 from the hard disk just cannot exist. (Note, I am not including
 access control programs that encrypt the whole disk and rely on
 input of the key by the user for decryption - this could be made
 "strong enough" - but a self-contained program cannot. Period.

         82 today - what Floridians put up with summer for,
                         Padgett

 ------------------------------

 Date:    Tue, 05 Jan 93 22:57:57 +0000
 From:    [e-mail] (student)
 Subject: Known virus that tweaks PC date function? (PC)

 In the office where I work, we recently purchased a 286 clone..  Over
 the past few weeks, the computer's internal clock has been losing
 days.  The first time, it stuck on Thanksgiving.  A week later, it
 hung on December 7th (Pearl Harbor Day).  A few weeks later, it stuck
 on Christmas Eve.

 Has anyone heard of a virus that would produce these symptoms?  If
 not, does anyone have any other ideas about how to fix the problem?

 Please respond via e-mail to:  [e-mail]

 Thanks!

 ------------------------------

 Date:    06 Jan 93 09:05:10 +0000
 From:    [e-mail] (Kevin Marcus)
 Subject: Re: Clash between FDISK/MBR and scanners (PC)

 [e-mail] (Roger Riordan) writes:
 >The command FDISK /MBR is often recommended for removing MBR
 >infectors (Stoned, etc) from hard disks.  However in some
 >circumstances this can cause problems with some scanners.  It
 >appears that some versions of FDISK/MBR rewrite the Master Boot
 >Record only as far as the end of the error messages, leaving the all
 >important partition information unchanged, but also leaving any
 >viral code between the messages and the partition information.

 I recently installed Linux, a version of unix for the PC, in addition
 to my regular dos partition.  This comes with a small program called
 "wini" which is a program, which occupies the MBR to allow me to
 choose which OS I would like to boot into.  It's my understanding
 OS/half does somethign like this, also, or can do something like this.
 If FDISK/MBR REWRITES the MBR with the basic, boring code that
 normally is there with DOS, then if I use this method, I will destroy
 the wini program, and restrict myself from booting into my Linux
 partition.  This is another drawback to fdisk/mbr.
 - --
 || Kevin Marcus, Computer Virologist.  (619)/457-1836; RE-xxx, TSCAN       ||
 || INET: [e-mail]       []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]
 ||       [e-mail]       || All I wanted was a Pepsi...            ||
 ||       [e-mail] ||       And she wouldn't give it to me...||

 ------------------------------

 Date:    06 Jan 93 09:06:21 +0000
 From:    [e-mail] (Fridrik Skulason)
 Subject: Re: Invalid Boot Sectors (PC)

 [e-mail] (Roger Riordan) writes:

 >It appears the original message got lost, but the gist was that,
 >IN THEORY, it is possible to write a BS virus which is invisible
 >on an infected PC, but impossible to detect on an uninfected PC
 >with any existing scanner because DOS will crash if any attempt is
 >made to access an infected disk.

 well, only if the scanner uses int 21H/25H/26H to access the disk.  If it uses
 int 13H to access the disk the disk can be read no matter what data is in the
 boot sector.

 - -frisk

 - --
 - --
 Fridrik Skulason      Frisk Software International     phone: [phone]
 Author of F-PROT      E-mail: [e-mail]         fax:   [phone]

 ------------------------------

 Date:    06 Jan 93 16:38:22 +0000
 From:    [e-mail] (David Rind)
 Subject: Joshi Question (PC)

 I have a question about the Joshi virus (yes, yesterday was January 5th).

 Does Joshi trap attempts at warm reboots?  There was an intermittent
 problem with a new program on a computer that turned out
 to be infected with Joshi.  The problem was sporadic enough that I
 can't be certain that getting rid of Joshi eliminated it, but if
 Joshi was trapping Alt-Ctrl-Del, then that would explain the "bug".

 I checked the info in F-Prot, and it wasn't that specific, and I'm
 not sure where else to check (my impression from reading this group
 is that there aren't many reliable sources for descriptions of
 specific viruses).  Thanks.

 - --
 David Rind
 [e-mail]

 ------------------------------

 Date:    Thu, 07 Jan 93 11:44:21 +0000
 From:    [e-mail] (Peter Duffield)
 Subject: PKZIP V2.04C (PC)

 I picked the following post up in comp.archives.msdos.announce and thought
 it may be of interest to this group...

 - --------------------------------- cut here -----------------------------

 From: [e-mail] (PKWare.Inc)
 Subject: PKZIP 2.04c RELEASED (NO VIRUS)
 Reply-To: [e-mail]
 Date: Thu, 7 Jan 1993 09:38:18 GMT

         PKZIP 2.04c is now released and on the PKWARE BBS (414-354-8670)

         Some reports have come in the certain version of Norton Anti-Virus
         are reporting PKZIP 2.04 to have the Maltese Amoeba virus.

         THESE REPORTS ARE FALSE! If the version of Norton is upgraded to
         a newer version the false reports cease.

         The correct files size,date and time should be:

         PKZ204C.EXE     188818  12-28-92        2:04
                         SIZE    DATE            TIME

         If you have any further questions, please feel free to contact
         me here at [e-mail]

         Mark Gresbach
         PKWARE, Inc.
 - --
 [e-mail]      Voice [phone]   Authors of PKZIP, PKLITE
 9025 N. Deerwood Dr.         BBS [phone]   PKZFIND, PKZOOM, and the
 Brown Deer, WI 53223 USA     FAX [phone]   Data Compression Library

 - --------------------------------- cut here -----------------------------
 Peter
 - --
 Peter Duffield                          [e-mail] (Internet)
 Voice: [phone]                   BBS:  [phone]   8,N,1
 North Wales Anti-Virus Support BBS, FidoNet: 2:250/201, VirNet: 9:441/110
 ===  PGP 2.0  ==  public key available on request  ==  Key ID 991AB1  ===

 ------------------------------

 Date:    06 Jan 93 21:03:27 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: False positive in the new PKZIP (PC)

 Hello, everybody!

 As most MS-DOS users probably know, the very popular archiver PKZIP
 from PKWare Inc. has not been updated from version 1.10 since about
 two years. The new version was in "about to be released final
 beta-test" during more than a year. This, of course, caused a lot of
 bogus, hacked, or trojanized versions to be released by malicious
 people to fool the legitimate users. The number of hacks is probably
 above 10.

 A few days ago, PKWare finally decided to release a new version of
 their archiver, called 2.04c. Regardless of the long developpment
 period, the program turned out to contain a few minor bugs and even
 errors in the documentation. But this is not so interesting from the
 computer virus point of view... :-)

 What is interesting is that somebody used an out-of-date version of
 Symantec's Norton Anti-Virus to scan the new archiver. It seems that
 this version causes a false positive - the program is flagged as
 infected by Maltese Amoeba. The confusion is increased by the fact
 that all executables in the package are self-compressed with PKLite
 1.20. This caused the heuristic scanner of F-Prot to report that those
 files are suspicious, because they contain a program that modifies
 itself in memory (of course - the decompressor unpacks the compressed
 code) - something often used by viruses.

 As a result, a major hoax was started; the archiver was several times
 uploaded and deleted at wuarchive.wustl.edu; and the number of
 messages about that in comp.compression is reaching the record caused
 by the famous posting that informed about the claims of a company to
 produce an archiver which is able to achive compression rate of 16:1
 for any file... :-)

 I obtained a copy of the new version of PKZIP, examined it manually
 with a debugger, and scanned it with about a dozen scanners. The
 result is that NONE OF THE EXECUTABLE FILES IS INFECTED. Even a recent
 version of NAV (2.1 with signature updates of December) does not
 report the false positive any more. PKWare has confirmed that this is
 a "real" version.

 So, please done's pay attention to the rumors, if they reach you. The
 VALIDATE codes of the self-unpacking archive containing the new
 version of PKZIP is:

           File Name:  PKZ204C.EXE
                Size:  188,818
                Date:  1-5-1993
 File Authentication:
      Check Method 1 - 0DC8
      Check Method 2 - 045E

 The actual Date: field may be different; it was destroyed while I was
 downloading the file.

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    Wed, 06 Jan 93 17:04:01 -0500
 From:    [e-mail] (A. Padgett Peterson)
 Subject: Info on Music Bug virus (PC)

 >From:    [e-mail] (Bill Lambdin)

 >The Music Bug virus isn't generally destructive, but the FAT table
 >structure on hard drives gives some weird effects occasionally.

 Not quite. The MUSIC-BUG is not *intentionally* destructive however
 mistakes do cause damage since this virus makes assumptions about disk
 structure that works only on some floppies and on no hard disks.

 The virus tries to create a "haven" for its code by searching for
 unused sectors and allocating them (six or seven as I recall).
 Unfortunately, while the chosen clusters are "safe", in computing the
 register values for a cluster/sector translation the M-B makes
 mistakes that cause the virus to write to a different set of sectors
 which may be in use.

 The virus also makes a single byte change to the Boot Parameter Block
 which renders removal via SYS C: unusable since the disk becomes
 unbootable.  For some time this led to the opinion that recovery was
 impossible but most vendors now use a equally simple recovery method
 that works (think it took less than 30 bytes).

 The most common vector was via a graphics driver disk furnished with
 certain computer systems and though the manufacturer was notified, I
 have never seen any indication that the disks were withdrawn/replaced.

                     Unseasonably warm & humid,

                             Padgett

 ------------------------------

 Date:    Wed, 06 Jan 93 23:52:02 +0000
 From:    [e-mail] (Daphne Rosenhouse)
 Subject: New Virus (PC)

 hi all
 Id like to report a new virus/mutation i found
 It looks like a variant of te WHALE, but larger, and harder to remove
 im researching it and will soon post the results and send  a sample to all
 anti-viral softs programmers...
 i just wanted to inform all users on comp.virus and VIRNET.
 p.s. do VIRNET users get messages from here too ?
 bye


 ------------------------------

 Date:    Thu, 07 Jan 93 01:22:10 +0000
 From:    [e-mail] (McAfee Associates)
 Subject: Re: Vshield vs Virstop (PC)

 Hello Bill Lambdin,

 You write:
 [regarding VSHIELD's ability to check validation (CRC) data created by SCAN]

 >2. These CRCs will not detect stealth infectors because stealth viruses
 >   disinfects infected files when an infected file is opened for any
 >   reason.

 VSHIELD (or SCAN) will detect the change in a CRC made by a stealth
 virus provided the stealth virus is not resident in memory to
 interfere with checking.

 Regards,

 Aryeh Goretsky
 Technical Support

 - --
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 McAfee Associates, Inc.  | Voice [phone] | INTERNET: [e-mail]
 3350 Scott Blvd, Bldg 14 | FAX   [phone] | IP# 192.187.128.1
 Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714

 ------------------------------

 Date:    Thu, 07 Jan 93 01:26:20 +0000
 From:    [e-mail] (McAfee Associates)
 Subject: Re: Jerusalem (Israeli) Virus (PC)

 Hello Bill Lambdin,

 You write:
 >Quoting from Samid Hoda to All About Jerusalem (Israeli) Virus on 12-20-92
 [asking about how to remove the Jersualem virus]

 >McAfee's Clean can remove this virus fairly easy to remove. It would be a
 >very good idea to re-boot the computer from a known clean bootable
 >diskette. If you don't have a clean bootable diskette, go ahead and type
 >the following on the command line.
 >
 >CLEAN C: [JERU]
 >
 [...deleted...]

 Since the Jerusalem virus also infects overlay files.  I would recommend
 the use of the the /A and /NOPAUSE switches, which tell CLEAN-UP to check
 all files on the disk for the virus and remove it if found regardless of
 their extension, and not to pause when it has filled up the screen with
 messages, respectively.

 Regards,

 Aryeh Goretsky
 Technical Support


 - --
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 McAfee Associates, Inc.  | Voice [phone] | INTERNET: [e-mail]
 3350 Scott Blvd, Bldg 14 | FAX   [phone] | IP# 192.187.128.1
 Santa Clara, California  | BBS   [phone] | CompuServe ID: 76702,1714

 ------------------------------

 Date:    Wed, 06 Jan 93 20:34:25 -0500
 From:    "Roger Riordan" <[e-mail]>
 Subject: Clearing out old signatures (PC)

 [e-mail] (A. Padgett Peterson) wrote recently

 > Enclosed is a DEBUG script that will create a 68 byte .COM file
 > (CLEAR.COM) that will zero out memory between the current load
 > position and the TOM. To use, ...

 The only trouble with this is there is a surprising amount of
 software which leaves active code in memory, but does not bother to
 tell DOS.

 To guard against possible unknown viruses like to Chinese Fish,
 which install themselves in high memory, but do not set the top of
 memory down, we recently added a feature to VET to fill unused
 memory with a diagnostic procedure which gives a warning message,
 and locks the PC, if anything attempts to execute unused memory.  So
 if you run VET, and an unknown virus of this type is already in
 memory, you get the warning as soon as VET calls an interrupt the
 virus has trapped.

 Ahh! Another loophole closed!  Unfortunately a big customer
 immediately complained some users could no longer log in.

 We investigated, & found that they were using Microsoft Lan Manager.
 When PROTMAN was run from CONFIG.SYS a block of code was installed
 at 7000:7800, but top of memory (as recorded at offset 2 in the PSP)
 remained 9FFF:0000.  If this code was overwritten by running VET (or
 anything else) before the user logged in, the system would crash
 when the program NBP.EXE was run as part of the log in procedure.

 We sent details of this to MicroSoft Support, but, naturally, never
 received any reply.

 We added an option to VET to disable this feature.  A significant no.
 of users have encountered similar problems.  Most have been using
 Lan Manager, but other programs may also have been involved.

 Roger Riordan                     [e-mail]

 CYBEC Pty Ltd.                                 Tel: [phone]
 PO Box 205, Hampton Vic 3188   AUSTRALIA       Fax: [phone]

 ------------------------------

 Date:    Wed, 06 Jan 93 23:44:33 -0500
 From:    Jack Davis <[e-mail]>
 Subject: DOS Serial Numbers (PC)

 Regarding the question of changing the SERIAL NUMBER of a DOS disk.
 An undocumented DOS function 69h which will GET or SET the serial
 number of a disk is discussed in PC Magazine, July 1992, V11N13, Page
 496.  A PASCAL program listing is included with the article and the
 program itself is avaiable from PC Magazine.

 Regards,

 Jack Davis
 [e-mail]

 ------------------------------

 Date:    06 Jan 93 08:44:34 +0000
 From:    [e-mail] (The Jester)
 Subject: Viral Code Access

 I REALLY don't mean to start this debate again but my personal
 experience have left me with little choice:

 The Situation:I am trying to get ahold of a certain virus because it
 implements certain features which are of central importance to a paper
 I'm writing. (Note:I am trying VERY hard to leave out all details
 because I want this to be a discussion of topic and not a hidden
 request, something the moderator has made clear he will not stand for
 and a request I intend to respect.) The problem is that for all
 intents and purposes I am a 'nobody'. I am a Junior at U.C.L.A.'s
 school of engineering and getting my degree in computer science and
 engineering. In addition just about everybody has a dead on
 prohibition against giving anyone their viral code, even though they
 got it from someone. So I have been totaly unable to get a copy of
 this virus.

 Solution:One researcher who shall rename nameless suggested that I
 call a virus exchange board in order to get a copy of the virus. In
 other words that I go skulk around with the miscreants who keep many
 of you employed so I can get the material I need for my paper. However
 its not just a matter of dealing with the lowest of the low. Many
 viral exchange bbses require you to upload a new virus in order to
 access their collection. Should I go out and write some hyper deadly
 virus so I can get into their collection in order to look at the
 virus that every researcher and his brother already has but is to
 scared to give out? Maybe I should just write a moderatly deadly
 virus? A dude? What?

 Is this how the anti-viral community wants to run itself? Is this
 'open and free exchange of information'?

 [Moderator's note: This is obviously a touchy subject.  I stand by my
 policy of keeping requests for live viruses off of the group.  At the
 same time, I certainly recognize the need to get virus samples to the
 appropriate people for analysis purposes.  I welcome thoughts and
 discussions on this issue.]

                 Yaron (The Jester) Goland
 - --
 "Only the blind see in color."
 "Any union based upon pigment is foolish ignorance designed to
 give power to those few who enjoy power's taste above the common
 welfare."

 ------------------------------

 Date:    Wed, 06 Jan 93 10:44:43 -0500
 From:    Olivier "M.J." Crepin-Leblond <[e-mail]>
 Subject: Re: The Internet Worm (CVP)

 >From [e-mail]  Fri Dec 25 08:15:00 1992
 >Date:    Fri, 25 Dec 92 00:15:35 -0800
 >From:    [e-mail]
 >Subject: The Internet Worm (CVP)
 >
 >HISVIRO.CVP   921215
 >
 >                         The Internet Worm
 >
 >By the fall of 1988, VIRUS-L had been established (let's hear it for
 >Ken!) and was very active.  Issues were, in fact, coming out on a
 >daily basis, so I was quite surprised when I didn't receive one on
 >November 3rd.  I didn't get one on November 4th, either.  It wasn't
 >until November 5th, actually, that I found out why.

 This is incorrect. The first digest of VIRUS-L appeared on 9th Nov 88.
 I suspect that this was triggered by the FLOOD of undigested messages
 that had to be sent all around the place during the week 1 Nov to 8th
 Nov 88. (am I right, Ken ?)

 [Moderator's note: For the e-record, VIRUS-L Volume 1 Issue 1 was
 posted Wednesday, 9 Nov 1988, just a few days after the Internet worm
 incident.  The primary input behind going digest+moderation at that
 time was a storm of ASCII "pictures" that were posted to the group.
 That, plus the added discussions due to the worm prompted several
 people (including myself) to want the list to go to digest format.  In
 any event, VIRUS-L was distributed unmoderated and undigested from
 Fri, 22 Apr 88 07:48:39 EDT (when I sent the first announcement to the
 newly formed group) until 9 November.  The distribution was from
 LEHIIBM1.BITNET aka IBM1.CC.Lehigh.Edu - the same IBM 4381 mainframe
 that served the group until July 1992, when we switched over - not
 without pain - to an RS6000 running AIX and IDA's sendmail.]

 VIRUS-L was a BITNET listserv list (LEHIIBM1.BITNET) and was just an
 email exploder, forwarding messages on BITNET and traffic went-on
 throughout the internet worm. I recall receiving messages here in UK
 via EARN-RELAY (known as UKACRL.BITNET). It was interesting to read
 messages as they came in. I remember spending most of the 4th of
 November 1988 on my terminal, reading message after message. (or was
 it 5th ?)

 Receiving so many messages per day was quite exciting, since I had
 only started to subscribe to VIRUS-L a week earlier. An amazing
 coincidence. Judging from the nonsense that was often written, the
 amount of confusion amongst those affected by the worm was at a peak.
 Rumours spread so quickly.

 - --
 Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department
  Imperial College of Science, Technology and Medicine, London SW7 2BT, UK
        Internet/Bitnet: <[e-mail]> - Janet: <[e-mail]>

 ------------------------------

 Date:    Wed, 06 Jan 93 16:50:11 +0000
 From:    [e-mail] (Gregory Robert Weiss)
 Subject: Re: Good use of (possible bad) viruses

 [e-mail] (Celustkova-k336-doktorand(Richta)) writes:
 >Hi boys and girls, (a day of inspiration,huh ?)
 >
 >Just one of those days...Two examples of good use of (possible bad)
 >viruses come to my mind :
 >
 >1. Viruses written to improve an A-V product
 >
 >The logic is simple. It is better that I write virus which can do this
 >or that and have prepared solution to implement in my A-V product than
 >wait that such virus arises in wild and then react. That means if I
 >know that today exist viruses which could be stealthy, tunneling or
 >polymorfic why shouldn't I write virus which is all that and design my
 >A-V product to recognize such virus before it really appears in wild.
 >(Well, maybe it is not commercial, I don't know).

 Developing solutions for anticipated problems is quite reasonable; however,
 the following statement isn't:

 >If such virus *by
 >accident* escape from my lab I already have a response and there is no
 >ethical problem at all.

 No problems if it "accidently escapes"...
  - unless of course you developed the virus and it "escaped by accident"
      before you had your A-V program properly detecting it.
  - unless you think about the fact that most people will not use *your* A-V
      program, they'll use someone else's, or maybe even no protection at all.
  - unless you consider that and you will create a lot of work for
      other A-V writers, and damage to others in the meantime.

 These problems are both technical and ethical problems that you must
 confront before doing this kind of work, IMHO.

 >2. Viruses built in an A-V product (it's just an idea, don't blame me if it
 >is not applicable in reality)
 >
 >Suppose that we have an A-V product which in regular intervals or
 >randomly send a virus in system. Virus (fast infector) infects only
 >programs which checksum doesn't correspond to previously calculated
 >values. If no such program is found virus deletes itself or removes
 >from memory. If changed program found virus activates scanner to check
 >if there is any known virus.  If known virus is found message is sent
 >to the user. If program is changed and no known virus is found the
 >message is sent to the user to make decision.

      This sounds fine and good for a strictly contained system owned by an
 A-V writer (note the dangers mentioned in my previous comment above),
 but will be *absolutely, fundamentally worthless* in an A-V product
 as you describe, because you are describing a system in which the
 virus is discovered (and hopefully removed) only *after* files have been
 damaged.  The point of having A-V products is to prevent the damage in
 the first place.

      So now my financial records which I hadn't backed up for a
 month or two (or more...) are damaged: my A-V virus says the checksum has
 changed.  Well, I'm glad that I caught that virus, even though it destroyed
 the data file I was trying to protect! :-)

      The reason why many A-V products are TSRs is to catch viruses *as* they
 enter the system, not *after* they enter the system.  Your A-V virus
 seems to fall short in this regard.

 >                        If decision is to leave
 >program as is, virus cuts itself from the program.  The whole process
 >(except messages) takes place in background. There is no need for all
 >A-V program (which is combination of I-checker and scanner) to be TSR,
 >only virus is occasionally TSR. There is slight similarity in this
 >idea with reaction of human immunity system. Anyone has ethical
 >problem with her/his own immunity system ?

 I understand your comparison is tongue-in-cheek, but you really are comparing
 apples and oranges here.  In the immune system, a few cells can die, but
 your body can still function properly.  Computer data files and programs
 are much less forgiving of a few errors.

 >Cheeeers,
 >
 >Suzana

 Happy New Year everyone!

   --Greg
     [e-mail]

 ------------------------------

 Date:    06 Jan 93 20:57:29 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: Export restrictions of anti-virus software?

 The following was provided by Robert Heuman from Canada in one of the
 newsgroups (sci.crypt, I think). It seems to imply that some kinds of
 anti-virus programs are restricted from export in Canada. I would be
 very interested whether similar export restrictions exist for the USA.
 Please note that I am interested -only- in export restrictions of
 anti-virus software, not in export restrictions of cryptographic
 software. Could somebody in the USA who has access to the full text of
 ITAR verify that? Please, if you find something, post the exact
 reference and quote, if possible. Thanks.

 Regards,
 Vesselin

 Date Entered: 12-22-92 10:34
 I was asked to supply information re export control over anti-virus
 software, since I stated it was restricted in some cases.

 The exact information follows:

 Source: A Guide to Canada's Export Controls, January 1, 1992

 Page 25, item 1150.Information Security

 NOTE: The embargo status of "information security" equipment,
 "software", systems, application specific "assemblies", modules,
 integrated circuits, components or functions is defined in this
 Category even if they are components or "assemblies" or other
 equipment.


 Page 25, item 1154. Software

 1154.a.c.3. "Software" designed or modified to protect against
 malicious computer damage, e.g., viruses.


 Page 1, General "Software: Note

 This List does not embargo "software" which is either:
 1. Generally available to the public by being:
     a. sold from stock at retail selling points, without restriction,
        by means of:
         1. Over the counter transactions
         2. Mail order transactions
         3. Telephone call transactions _AND_
     b. Designed for installation by the user without further
        substantial support by the supplier, _OR_
 2. "In the public domain".

 A check with Ottawa resulted in the statement that F-PROT was export
 restricted (controlled) as shareware did not meet the criteria of this
 general "software" note... Therefore SCAN by McAfee also would not
 meet the requirements.

 I believe a similar restriction will be found in the US regs, as
 Canada's are based in good measure on the US regs, and this specific
 restriction was added at the request of the US gov't.

 Bob
 - ---
    RoseReader 1.70 P001886: Twice as human as anyone else my opinions are my ow
 n
    RM 2.00 : RoseNet<=>Usenet Gateway : Rose Media 416-733-2285
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 Date:    06 Jan 93 21:21:12 +0000
 From:    [e-mail] (Vesselin Bontchev)
 Subject: How to measure polymorphism?

 Hello, everybody!

 There are already two polymorphic engines available (MtE and TPE) and
 we are going to see more and more polymorphic viruses in the future.
 An interesting question arises - how to determine how polymorphic a
 virus is? How to determine which of two viruses is "more polymorphic"?
 In other words - how to measure polymorphism in an objective way?

 There are several ways one could think about:

 1) Determining the total number of different instance that a
 particular virus can take. Obviously, a virus that can take 6
 different appearances (V-Sign) is less polymorphic than a virus that
 can take 65,536 (Cascade).

 Unfortunately, this does not work. First, for some viruses it is
 almost impossible (well, at least too difficult) to count the total
 number of appearances. Nobody has succeeded yet to determine the exact
 number of different decryptors that MtE can generate.

 Second, a variably encrypted virus with the following decryptor

         mov    si,code_end
         mov    cx,code_length
         mov    ax,key
     decode:
         xor    word ptr [si],ax
         jmp    short skip

     garbage    db    ?

     skip:
         dec    si
         dec    si
         loop    decode

 where the byte 'garbage' can take any value is not very polymorphic,
 regardless that the number of possible decryptors is 256. If we change

     garbage    db    ?

 to

     garbage    dw    ?

 this will mean that the number of possible decryptors is 65,536, but
 the virus is not more polymorphic...

 2) The second idea is to divide the polymorphisms is classes. Class 0
 means no polymorphism, class 1 means variable encryption with constant
 decryptor, class 2 means variable encryption with a decryptor that can
 be detected by a wildcard scan string, class 3 is a virus that cannot
 be detected even with a wildcard string. E.g., Vienna (class 0) is
 less polymorphic than Cascade (class 1), which is less polymorphic
 than Suomi (class 2), which is less polymorphic than V2P2 (class 3).

 Unfortunately, this is not good enough. First, what to do with viruses
 that use a limited set of decryptors, one of which is selected
 randomly (Whale). Such viruses are obviously more polymorphic than
 Cascade. But are they more or less polymorphic than Suomi? They can be
 detected by a set of non-wildcard strings...

 Second, what about Bad Boy? It consists of 9 segments of code, 8 of
 which can appear in any order. This gives 8! = 40,320 variants. But
 the virus is even not encrypted, so it can be detected with a simple
 (non-wildcard) scan string...

 Third, what is a "wildcard string"? A string allowing "don't care"
 bytes? A string allowing "don't know how many don't care bytes"? A
 string allowing "don't care" bits? For instance, Maltese Amoeba cannot
 be detected by the user-defined scan strings of SCAN or F-Prot, but
 can be with the wildcard scan strings of HTScan/TbScan... So, is
 Maltese Amoeba class 2 or class 3 polymorph?

 Fourth, what about V2P2 and V2P6Z? None of them can be detected by a
 scan string (even a wildcard one), but most experts agree that V2P6Z
 is "more polymorphic" than V2P2 - because the decryptor can be of
 different length, the virus too, and many other things...

 3) The third idea was proposed by Dr. Solomon. He proposes to use the
 length of the longest byte sequence that is present in the decryptor.
 As an addition, one could use the sum of the length of all constant
 byte sequences in the decryptor - if there are several short ones that
 can appear in any order (like it is in V2P2).

 This is already better, but still not good enough. According to this
 criterium, the MtE-based viruses have polymorphism 1 - because all
 decryptors contain only a single constant byte (the JNZ instruction),
 which does not appear at a constant place. (Obviously, by this
 criterium, the higher the number, the less polymorphic the virus is.)

 Unfortunately, as I said, this is still not good enough. There are
 other viruses with only a single constant byte in the decryptor, which
 are much less polymorphic than the MtE-based ones. On the other side,
 the TPE-based viruses can have 0 constant bytes in the decryptor, but
 this does not imply that they are more polymorphic than the MtE-based
 ones... In fact, if one looks at them very carefully, it is possible
 to see that the different decryptors are pretty similar, if you remove
 the garbage ("do-nothing") instructions...

 It seems that what each anti-virus researcher considers as "level of
 polymorphism" is dependent somehow on the technique he uses in his
 anti-virus product to detect polymorphic viruses. For instance, V2P6Z
 might look "more difficult" (i.e., more polymorphic) than the
 MtE-based viruses to those people whose scanners depend on the number
 of addressing modes used by the instruction that performs the actual
 decoding...

 This article is not meant to provide a solution of the problem. I am
 trying just to explain the problem and am asking for solutions. Any
 ideas are welcome - we really need an objective way to measure the
 level of polymorphism...

 Regards,
 Vesselin
 - --
 Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
 Tel.:[phone], Fax: [phone]      Fachbereich Informatik - AGN
 < PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
 e-mail: [e-mail]    D-2000 Hamburg 54, Germany

 ------------------------------

 End of VIRUS-L Digest [Volume 6 Issue 5]
 ****************************************